Rust integration (experimental) #99

SirVer · 2023-09-15T15:07:07Z

This is using cxx.rs to wrap the framework library and calling it from Rust. This code is currently only supporting providing an interface to be implemented, i.e. no variables publish or receiving and no calling of other interfaces. Those features are straightforward, quick and easy to implement, but for now this is probably enough to iron out the integration questions.

See the everestrs/README.md for more details on the implementation.

Co-authored-by: Dima Dorezyuk ddo@qwello.eu

everestrs/everestrs_sys/everestrs_sys.cpp

everestrs/everestrs/build.rs

everestrs/everestrs/src/lib.rs

everestrs/everestrs_sys/everestrs_sys.cpp

everestrs/everestrs/src/lib.rs

everestrs/CMakeLists.txt

everestrs/everestrs/Cargo.toml

Signed-off-by: Holger Rapp <HolgerRapp@gmx.net>

SirVer · 2023-09-22T18:00:55Z

All comments addressed. The cpp linter is wrong btw, module_id_ is used: https://github.com/sirver/everest-framework/blob/hrapp/initial_rust_support/everestrs/everestrs_sys/everestrs_sys.cpp#L58

a-w50 · 2023-09-27T06:54:16Z

cmake/cxxrs.cmake

+      OUTPUT ${output_dir}lib.rs.h ${output_dir}lib.rs.cc
+      COMMAND ${CXXBRIDGE} ${CMAKE_CURRENT_SOURCE_DIR}/${module_name}/src/lib.rs --header -o ${output_dir}lib.rs.h
+      COMMAND ${CXXBRIDGE} ${CMAKE_CURRENT_SOURCE_DIR}/${module_name}/src/lib.rs -o ${output_dir}lib.rs.cc
+      DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${module_name}/src/lib.rs
+      COMMENT "Generating cxx for ${module_name}"
+      VERBATIM


rather than calling the cxxbridge util here directly, I would call cxx_build::bridge from within the build.rs

I think, it should be the concern of this cxxrs.cmake script to figure out the path of CXXBRIDGE and not if its including script

The first one is a chicken and egg though: You would need to run cargo build to get the cpp code, which you need to run cmake to build the static C library, which cargo needs to link against. I.e. you would need to run cargo for only the build.rs file (which I do not think is possible), then run cmake, then cargo again. I think doing it here is the only possibility.

I do not understand this comment. Can you expand?

everestrs/CMakeLists.txt

a-w50 · 2023-09-27T07:00:51Z

everestrs/CMakeLists.txt

+    everest::log
+)
+
+install(TARGETS everestrs_sys LIBRARY)


I wouldn't binary ship this glue code library, as it depends on auto-generated stuff (`rust/cxx.h'), which will only be generated, when its using crate is build.

I do understand that you do not like the installing piece, however the comment is not actionable to me, I do not know what to do instead: To build any crate using everestrs, this library must be findable. The only way I know to make it findable is by installing it, that seems the EVerest way to go. If you have a better suggestion, I would be happy to try it out, but likely in a followup MR.

everestrs/Cargo.lock

everestrs/Cargo.toml

everestrs/everestrs/src/lib.rs

everestrs/everestrs/src/schema/interface.rs

Signed-off-by: Holger Rapp <HolgerRapp@gmx.net>

SirVer · 2023-09-28T12:32:42Z

Thanks for the approval. I have no rights to merge this though, who can help me with this?

hikinggrass · 2023-09-28T15:19:41Z

Thanks for the approval. I have no rights to merge this though, who can help me with this?

I can merge this, one minor thing would be to run clang-format over the c++ code, we do have a dockerized version of the exact version we require here, but you can see the output as well in the Lint step of the github action.

One example command line would be: (maybe adding --user to provider your correct userid/groupid)

docker run --volume "$(pwd):/source" [ghcr.io/everest/everest-clang-format:latest](http://ghcr.io/everest/everest-clang-format:latest) -r /source --extensions "hpp,cpp" -e "/source/cache" -e "/source/build" -e "/source/build-cross" -e "/source/build-clang" -i

Signed-off-by: Kai-Uwe Hermann <kai-uwe.hermann@pionix.de>

SirVer · 2023-09-28T17:58:43Z

@hikinggrass Thanks for doing the formatting for me. I tried myself and the container does not run for me (MacOS Arm64):

docker run --volume "$(pwd):/source" ghcr.io/everest/everest-clang-format:latest -r /source --extensions "hpp,cpp" -e "/source/cache" -e "/source/build" -e "/source/build-cross" -e "/source/build-clang" -i
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
run-clang-format: error: Command '['clang-format', '--version']' returned non-zero exit status 255.

It seems the linking inside the container is not done correctly, though I am confused by the qemu-x68_64

hikinggrass · 2023-09-28T18:03:44Z

@hikinggrass Thanks for doing the formatting for me. I tried myself and the container does not run for me (MacOS Arm64):
docker run --volume "$(pwd):/source" ghcr.io/everest/everest-clang-format:latest -r /source --extensions "hpp,cpp" -e "/source/cache" -e "/source/build" -e "/source/build-cross" -e "/source/build-clang" -i
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
run-clang-format: error: Command '['clang-format', '--version']' returned non-zero exit status 255.
It seems the linking inside the container is not done correctly, though I am confused by the qemu-x68_64

Ah that actually makes sense, since our container was initially just meant for the github action it just uses a prebuilt clang-format binary for x86-64. That then obviously doesn't work on arm64

SirVer mentioned this pull request Sep 15, 2023

First example of a Rust module implementation EVerest/everest-core#344

Merged

SirVer force-pushed the hrapp/initial_rust_support branch from d0734cf to 6bc4623 Compare September 15, 2023 15:10